1. Field of the Invention
This invention relates to communications between constituent elements of a data processing system. More particularly, it relates to communicating changes in processing capability between an operating system and a service call logical processor.
2. Background Art
In systems such as IBM's S/390, the Processor Controller Element (PCE) or Service Processor (SVP) is used for monitoring of the Central Processor Complex (CPC), its recovery, and reconfiguration.
Traditionally, interactions between a control program (CP) running on a central processor complex (CPC) and the processor controller element (PCE) or service processor (SVP) are performed by means of Service Call Logical Processor (SCLP) commands. The SCLP is a logical entity that may be comprised of several hardware elements. Commonly, on high-end processors, the SCLP is a part of the PCE; on low-end processors, the SCLP functions may be part of the SVP or may be a combination of CPU microcode and the SVP. In general, since the SCLP is a logical entity, its functions may also be performed by devices attached to the PCE or SVP, including a connecting network.
The SCLP command mechanism allows the CP to request the SCLP, wherever it is actually implemented, to perform a specific action. Execution of an SCLP command, from the view point of the control program, consists of two phases: issuance of the SCLP command, and completion of the SCLP command. The SCLP command is issued by means of the Service Call instruction (SERVC).
In the past, the method for interactive communication from the CP to the SCLP was often inefficient in getting the SCLP to process software (CP) requests in a timely manner.
1. The processors (PCE/SVP) that execute the SCLP commands are relatively slow compared to the processing speed of a CPU where the CP executes. PA1 2. It is very disruptive for the CP to do extensive preparation, to have to suspend its processing while waiting for the solicited interrupt, and then to learn after the fact that a request sent to the SCLP cannot be processed by the SCLP. PA1 1. Condition codes set by instructions (after the fact notification). PA1 2. Response/reason codes for service calls indicating not installed or inactive SCLP functions (also after the fact). PA1 3. Disablement for interrupts (indicates a DESIRE to avoid processing of designated interrupt, NOT the inability to process it). PA1 4. Read-SCP-Info SCLP command provides data on installed hardware facilities (static designation of installed, but not necessarily active facilities). PA1 5. The Service Processor Damage (SPD) machine check that indicates loss of SCLP function. This has no capability to indicate whether loss is temporary or permanent, or if function is ever subsequently restored. Furthermore, the SPD machine check indicates complete loss of SCLP functions, and has no way of indicating any subset of function that may still be available and unaffected by the problem. PA1 1. It required the CP to incur the additional overhead of a potentially unnecessary use of the interfaces for each and every request. PA1 2. The interface between the CP and SCLP can handle only one SCLP command at a time thereby placing additional overhead on the CP to manage a queue of requests. The need to enqueue and try requests that are destined to fail increases this problem. PA1 3. The CP often did not receive timely notification when the SCLP was incapable of satisfying a request. On some machines, the SCLP functions can take several seconds to perform. If the CP is forced to actually issue a request to learn that it cannot be serviced, the CP might have to wait that interval for the SCLP to complete another operative function before being notified that his request cannot be satisfied. PA1 4. When multiple functions are inoperative, they can be detected only one at a time when the need to use arises. PA1 5. The inefficiencies inherent in items 1, 2, 3, and 4 exist for the life of the system and must be repeated each time an inoperative function is desired. When a sender first receives a response indicating that the receiver cannot perform a given function, the sender cannot assume that the function is permanently inoperative and not submit any subsequent requests. The correct assumption has to be that both the SCLP and the CP can dynamically acquire and lose processing capability during the operation of the system. Therefore, each time a function is required, the request must be resubmitted and the resultant overhead and rejection is experienced again and again. PA1 6. During the interval between issuance of the SCLP command and the arrival of the SS interrupt indicating SCLP command completion, the "waiting" program (whether it is the CP itself or an application program running under the SCP) will probably be unable to respond to signals from other external sources (such as an operator or another CP). This, in turn, might cause the issuer of this other signal to take some disruptive, unnecessary recovery action (such as terminating the waiting program). PA1 7. No method existed to indicate only a partial loss of SCLP function. The SPD machine check means that the entire SCLP is not available. PA1 8. No method existed to indicate reacquisition of the SCLP and SCLP function when the prior loss of either full or partial function was only a temporary outage. PA1 1. The one-way only communication does not permit the SCLP to initiate a transaction or a conversation to the CP. PA1 2. Only one SCLP command can be issued at a time by the control program. PA1 3. The processors (PCE/SVP) that execute the SCLP commands are relatively slow compared to the processing speed of a CPU where the CP executes. PA1 1. The requirement that operator control of both the hardware and software of a CPC be done from a single console has been met by designating the hardware console (i.e., system console), which is attached to the PCE, as the single control point. This means that the PCE and CP must have new interfaces to pass messages and commands between the CP and the operator at the system console. PA1 2. Events perceived or performed by the SCLP may require processing by the CP. Therefore the SCLP requires a way of notifying the CP that an event has occurred and to pass event-related data to the CP. PA1 3. Multiple CPCs that are connected to each other in a network or SYSPLEX environment require that the SCLP on a given CPC be a two-way conduit for data and commands between its own CP and the other CPCs in the network or SYSPLEX. PA1 1. Establishment of a two-way communication between the CP and the SCLP. PA1 2. The SCLP interface to represent a physical connectivity path in the larger network that encompasses multiple heterogeneous machines and control programs. Such a path can be used for remote operations, distribution of service, error data collection, etc. PA1 3. Multiplexing of requests for processing of multiple concurrent functions. PA1 4. The SCLP to send data to the CP without solicitation by the CP. PA1 5. The SCLP to request actions to be performed by the CP and to receive back reports of completion of those actions. PA1 1. To pass and solicit information from the other, and to notify each other of their initial capability to handle the other's request to process an SCLP event. PA1 2. To subsequently and dynamically notify each other whenever there is an increase/reduction in their processing capability. PA1 3. To determine what events can be handled by the other, and to send just those requests that the other can handle. PA1 1. A sender knows before hand for any required function, whether the receiver can perform that function. Both the SCLP and the CP can dynamically acquire and lose processing capability during the operation of the system and can quickly notify the other about the change in operative state. PA1 2. The sender is not forced to actually issue a request to learn that it cannot be serviced. This avoids waiting for the SCLP to complete another operative function before notifying the sender that his request cannot be satisfied. This lets the sender continue to respond to signals from other external sources, and avoids taking some disruptive, unnecessary recovery action (such as terminating the waiting program). PA1 3. When multiple functions are inoperative, this can be detected simultaneously. PA1 4. SCLP, as an intermediate node in passing an event from a external originator to the CP, can now return some acknowledgement (if required) to the originator of the event that it was received at its final destination (an application running under the CP). The SCLP also does not need to "remember" events that it has passed to the CP. PA1 5. The situation where the receiver of an event may be operational but in a state (for example, performing recovery processing) where it cannot process the event can also be predetermined. The sender avoids the situation where it is left with the impression that the event processing succeeded.
Depending upon the particular command requested, the SCLP may take anywhere from one second to several minutes to complete the command. PA2 In some cases, the CP has to poll the SCLP at a regular interval to determine if the SCLP has information to present to the CP. The CP is said to be soliciting the information from the SCLP. PA2 Until the active SCLP command completes and the service-signal interrupt is presented, any other SCLP requests are rejected by the hardware. If the CP has multiple users overlapping their requests to the SCLP, the CP has to serialize the requests. PA2 Depending upon the particular command requested, the SCLP may take anywhere from one second to several minutes to complete the command. PA2 a. The SCLP interface is now a peer-to-peer interface. PA2 b. The SCLP can initiate the transmission to the CP of complete or segmented transactions originated by end applications/functions. PA2 Since the sender knows ahead of time that a given request cannot be performed, that request is not made. The related "request queue" is therefore shorter, resulting in improved performance and throughput for both the sender and receiver (and any intermediate data-transfer node in a network).
With the prior art, the CP had to try before it learned that a function was not available for a request and had no indication that the unavailability was temporary or permanent. The following are other prior art mechanisms for notification of failure or inability to perform a function:
The CP learns the results of the SCLP activity by interrogating SCLP response information. This is the first indication to the CP that requested event was available and that is could or could not process the request.
This method has resulted in the following problems:
In the past, the method for interactive communication from the CP to the SCLP was often inefficient in getting the SCLP to process operating system requests in a timely manner. Limitations include:
More complex installation requirements combined with new and improved data processing hardware have produced the need for flexible two-way communications between the SCLP and CP that is running on that CPC. This improved "communication" consists of the passing of data, messages, and/or commands from either the CP or the SCLP to the other. For such unsolicited information coming from the SCLP to the control program, it also became necessary to have the SCLP present such information to the control program as soon as the SCLP is aware of its existence, without requiring the control program to periodically poll the SCLP for the existence of such information.
There are three major reasons for developing two-way communications between the SCLP and the CP.
With the growth of new system functions and applications that use various SCLP facilities, it will be necessary to permit multiple concurrent users of SCLP functions. It also will be necessary to overlap execution of SCLP functions and to improve efficiency of the CP/SCLP data transfer by transferring different types of unrelated data on a single SCLP command.
With the growth of new functions and applications resulting in increased frequency of use and new uses of SCLP functions, it will be necessary to improve performance of the SCLP interactions. The performance improvements will result from concurrent, parallel execution of unrelated functions.